What tool do you want to use to automate updates of packages? Is there code available publicly?

Not yet, it's in development. It's going to be a python script and for the fedora part it will implement workflow described in https://fedoraproject.org/wiki/Package_update_HOWTO#Later_Branched_and_stable_releases . Code (early version) will be available publicly this week as soon as it's some kind of usable state.

Not that I get official vote on this, but I would be against this without seeing real code and doing some autdit...

Fair point, I'll update this with a link to source code when it's available.

I am good with the idea or a bot doing things, I would like some more data about how the bot works, services to run in infra will need a code review by @puiterwijk how and where do you plan to deploy and manage the bot?

Howdy,

as @jkosciel pointed out, we are planning for the bot to handle our upstream releases and propagate them to downstream(s) right away (basically the same thing cockpit does). Our software should be released frequently (twice a month) and we don't want to spend time running the manual steps every single time. Initially, bot will just handle conu but I expect it to babysit more (our projects) in the future.

Deployment? Well, our current plan is to put it inside internal OpenShift cluster. I understand this is not something Fedora would like. The bot will be containerized so if you guys have an OpenShift cluster where we can just shove it in, great!

@jkosciel is working on the code these days so it should be available (and fully open source) soonish.

Hi again!
It's been a while, sorry to keep you waiting. I managed to publish the code in a repository. This roughly implements our workflow, there are going to be changes regarding code improvements, but the logic will be the same. You'll probably be mostly interested in release_in_fedora() function where the logic is contained.

The workflow is as follows:
1. Clone dist-git repository and make sure the branch is master
2. Pull the sources (rather unnecessary since update only proceeds if there are new sources)
3. Copy spec file from upstream repository
I was told there might be problem with this, so let me explain. We store our spec file in the upstream repository, and a new release means preparing a new spec file (see here). Having the other option, bot preparing the spec file would mean we would have to have some sort of configuration for each release anyway, and it would restrict us from making changes to spec file itself while utilizing the automated release from upstream.
4. Pull new sources using spectool
5. Add these new sources
6. Commit, push, build
7. Cycle through branches from configuration and merge master, push, build
We are aware that merge conflicts can arise here, and plan on fixing them by hand if they do.

TODO:
- expand step 7 by adding automated submitting to bodhi

Please keep in mind this is a prototype and code might not be perfect, but the logic will be like this.

@jkosciel note that throwing away of fedora changes in spec file is prohibited by packaging guidelines.

Igor, that is a very good point. The plan is to sync the downstream spec file to upstream (so we maintain only a single copy of the spec file) , verify in upstream it works fine and then distribute it back downstream. If you guys have a better idea, we're all ears.

And obviously, even if our automation rewrites anything downstream, we can always revert or introduce the changes back.

Edit: based on Igor's comment, we decided to edit the Fedora spec file instead of rewriting it. Packaging changes will be performed asynchronously (of releases).

Hi again,
I'm back with some updates. We decided to correct our workflow in step 3:

1. Copy spec file from upstream repository
   I was told there might be problem with this, so let me explain. We store our spec file in the upstream repository, and a new release means preparing a new spec file (see here). Having the other option, bot preparing the spec file would mean we would have to have some sort of configuration for each release anyway, and it would restrict us from making changes to spec file itself while utilizing the automated release from upstream.

This will happen instead:
3. Edit the upstream spec file (the dist-git one) with info from repository release configuration (changed with every release)
Changed items will be Version number, Release (always to 1 as bot will only handle initial release) and adding a changelog for the version. Changelog will be specified in release config

For code changes you can check out the repository

Some comments:
- https://github.com/kosciCZ/release-bot/blob/master/bot.py#L244
this is bad. You shouldn't merge the master branch into other branches, because this brings in (possibly) unwanted changes and changelog entries. Iff the branches are the same originally, you should commit to master and then fast-forward other branches. Otherwise, the change for each of the branches should be prepared from scratch. After all, this is all automatized, so it's not any more work.

In general the style of combining multiple bash commands using && and pasting the whole string to a shell to execute just is doesn't seem great. There's subprocess.run which isn't any harder to use, when combined with f-strings the code would probably be even shorter, but it avoids issues with shell quoting, spaces in filenames, and a bunch of other stuff. Error handling would also be much more precise. Since this is something that you want to "unleash" on a whole bunch of diverse repos, I think it'd be nice to make the code robust.

• https://github.com/kosciCZ/release-bot/blob/master/bot.py#L243
  subprocess.Popen anddecodeandcommunicatecan be replaced withsubprocess.run(..., universal_newlines=True)`.

• https://github.com/kosciCZ/release-bot/blob/master/bot.py#L363
  f-strings, please. It's 2018 after all.

Hi!
Thanks for the comments. I implemented the requested changes.

If the branches are the same originally, you should commit to master and then fast-forward other branches. Otherwise, the change for each of the branches should be prepared from scratch.

I changed merging in branches other than master to merge only if they can be fast forwarded. If not, branch spec file is modified same way it was on master and a new commit is created on this branch (code)

subprocess.Popen and decode and communicate can be replaced with subprocess.run(..., universal_newlines=True).

I also implemented this, thanks for the suggestion.
(code)

f-strings, please. It's 2018 after all.

Also done.

I also PyLinted my code and fixed issues that were discovered (including proper documentation) so I hope the code looks better now and I also hope that the workflow in Fedora repositories is now more like what you think it should be.

I'm +1 with the overall idea of granting the account.

I'm +1 to the idea of granting the account. (I have some concerns about the implementation of the workflow, but it looks like those concerns have already been addressed here in the FESCo ticket.)

+1 to the idea of granting the account

AGREED: FAS bot account sponsoring is accepted, with the provision that it should be clear that the account is a bot and that owners are responsible for any actions it takes the same as for their own actions (+7, 0, 0)

I have added a comment on the FAS account that indicates it is a bot and declared it's owners and provided a way to contact them. We understand and acknowledge the responsibility we have for actions of the bot.

Thank you for cooperation.