well, you should have discussed with Artwork SIG lead for this as he's aware of the existing process : staging branch is always reflected on https://www.stg.centos.org/ so I don't see why we need a different process :)

@areguera : ^

@shaunm : can I just close this ticket ?
You'll just have to verify with @areguera what's needed (if anything needs to be done at infra level, as if that's the same jekyll container, nothing is needed at all at infra side) ... and then reopen a ticket with info ?
PS : worth knowing that myself I'll have PTO days here and there so don't expect me to be available $last_minute

@shaunm could you move your revamp changes to staging branch so they can be automatically visible in https://www.stg.centos.org/ ?

also : is that still with actual theme or would it need the new container that @areguera was preparing through artwork sig for new centos theme ?

I merged revamp into staging. The changes aren't being published. Possibly failing pipeline due to dep changes with the new theme?

Well, the container/workflow used is the official jekyll/jekyll container, so probably not having everything that it is required, reason why I thought (hoped ? ) that you'd have discussed with @areguera first about requirements and so what would need to be done at infra side.
I initially thought it would be just a container change (from https://gitlab.com/CentOS/artwork/centos-web/jekyll-theme-centos/container_registry) but it doesn't seem to be the case :

podman run --rm -it registry.gitlab.com/centos/artwork/centos-web/jekyll-theme-centos:v2.51.1-beta.68 jekyll -v
Error: crun: executable file `jekyll` not found in $PATH: No such file or directory: OCI runtime attempted to invoke a command that was not found

My proposal :
* you discuss about what's needed
* you write requirements
* I can already modify the ansible role that renders both www and www.stg hosts to use a specific container (full path, including tag)

For that last idea, I was thinking about using something like container.specs file in git repository itself, that can be parsed at runtime when rendering/pushing built content and so verify that we're running correct container. That would permit Artwork SIG (and people contributing to centos.org website content) to pull correct container, and not having to deal with (undocumented) rubygems dependencies, but also be independent and not rely on infra to modify/update container version/tag to reflect a needed change.

Opinions ?

PS : where was all that discussed first ? it seems it wasn't and reason why I'm concerned

FWIW, I had a look at reason why it doesn't even build on staging for now :

public_suffix-6.0.0 requires ruby version >= 3.0, which is incompatible with the current version, ruby 2.7.1p83

I see in the Gemfile that it needs at least jekyll 4.3.0 (gem "jekyll", "~> 4.3.0") but that official jekyll container seems unmaintained and stopped at 4.2.2 ? (see https://hub.docker.com/r/jekyll/jekyll/tags?ordering=name)

So I'll let you see about the needed container that can be used to render staging now and we'll see about fixing it first in staging and then it will be automatically done for main branch

FWIW, I had a look at reason why it doesn't even build on staging for now :

public_suffix-6.0.0 requires ruby version >= 3.0, which is incompatible with the current version, ruby 2.7.1p83

I see in the Gemfile that it needs at least jekyll 4.3.0 (gem "jekyll", "~> 4.3.0") but that official jekyll container seems unmaintained and stopped at 4.2.2 ? (see https://hub.docker.com/r/jekyll/jekyll/tags?ordering=name)

Yes. That's one of the reasons I moved the rendering process to jekyll-theme-centos container image. It uses jekyll gem directly and we can introduce updates as they are released. Consequently, as we are using jekyll gem, it is necessary to update the render command we previously used to bundle exec jekyll.

I updated the README file in the staging branch and also added a Makefile with commands for you to reproduce the rendering process yourself.

Note that files like Gemfile and Gemfile.lock are no longer necessary because the theme container image already provides them. Site maintainers only need to put focus on content files. Everything else has been packed inside the jekyll-theme-centos container image. To know more about jekyll-theme-centos theme see documentation.

Please confirm if you are able to reproduce the site rendering process using jekyll-theme-centos container image and the commands described in the README.md file.

Thanks!

yes, thanks .. I confirm that with documented instructions I'm able to build website on a different host.
Now working on what's needed in ansible role (and newer build host , running el9) to reflect needed changes, and expect www.stg.centos.org to point to new host this week

@areguera , @shaunm : https://www.stg.centos.org is now rendering from new container but something is really looking bad so I'll let you verify the .css or else.
Running locally with jekyll serve shows all correct css/links/layout .. but the copied _site/* to public documentroot seems to be referencing www.centos.org links (so probably reason why it's broken ? )

found it : it's hard-coded in _config.yml so reason why it's rendered differently
So either we just have different one for staging and so I have to adapt the config file to use. or we just keep different versions in main and staging branches but that will be interesting to merge back from one to the other (or rebase) as there will be conflicts.

For the time being, I just manually updated it on that host to be able to render it
Let me know your thoughts/opinions about how you wanted to deal with it

What about using two _config.yml files (e.g., _config.yml for prod, and _config-staging.yml for staging), setting the proper values for each environment therein, then update the container command in each environment to point its configuration file using the jekyll --config option during the build process?

Yes, what I thought but then eventually _config-main.yml and _config-staging.yml so that it would reflect branch name ... and fwiw, _config-main.yml can have a simple _config.yml symlink (to not confuse users)

I pushed commit that implements that and ansible role is modified to take that into account too (to be ready for real www.centos.org migration once, staging branch will be merged back into main one - but plenty of content has to be added there)

Closing for now but I'll create a Artwork ticket as I saw that the javascript that used to select/filter aws-images is gone ?

Compare https://www.stg.centos.org/download/aws-images/ and https://www.centos.org/download/aws-images/
As said, created ticket on Artwork SIG issue tracker