I had learned that the appropriate way to re-check a new tag after some minor correction was to close and then reopen the pr. It would help if my use of attobot did not preclude that close and reopen action, or something with the same outcome.

This seems to have broken a week or so ago, anything in the logs that indicates why?

https://github.com/invenia/Intervals.jl/releases/tag/v0.0.7

NOTE: For now I've just manually updated METADATA

Attobot could detect issues, e.g. wrong minimum Julia version, and automatically reject the PR to METADATA, without having to waste CI and developer time waiting to see what happens.

Is it possible not to trigger attobot in a repo when I make a release?

Without, of course, removing it globally and allowing it only for specific repos (ie all but a particular one).

The particular repo is https://github.com/tpapp/skeleton.jl, which is just a script, not a package.

I'm not sure if this is in the realm of possibilities. But it would be interesting to see if it's possible to add reminders to tag a package for new commits that have been available on master for more than x days/months. This would help remind package authors to tag updates to their packages

E.g. julia-vscode/julia-vscode#137 and julia-vscode/julia-vscode#136.

Why is it even monitoring that repo?

This release https://github.com/goropikari/Notifier.jl/releases/tag/v0.0.1 did not create a METADATA PR.

This release: https://github.com/JuliaCollections/Iterators.jl/releases/tag/v0.3.1
did not create a METADATA PR or issue on Iterators.jl.

I had a bad tag that wasn't semvar'd properly, so I updated the tag. But I don't think Attobot is still watching. It would be great if I could manually trigger attobot once the release is fixed.

for context: https://github.com/econtoolkit/Expectations.jl/releases

When for example I bump the version of IndexedTables required by JuliaDB from 0.4.2 to 0.5.1, it would be nice if attobot goes through the require file of all the previously tagged versions of JuliaDB and puts an upper bound of 0.5.1 (exclusive) if an upper bound doesn't already exist.

For example if there already exists a version v0.1.0 of some package which is 0.6 only, and I want to tag a backport v0.0.2. Right now it would compare against v0.1.0 instead of v0.0.1.

see JuliaLang/METADATA.jl#8724 for an example

Note that it works properly, it is just the PR message that is a bit unhelpful in such cases

I swear I did it right this time (:)) but Attobot didn't pick it up:

https://github.com/cormullion/Luxor.jl/releases/tag/v0.7.0

Is there like a queue or log or something where you can check on progress?

Attobot's cool so I want to get it working...

Possibly doing something silly on my end, but I just tagged Clp.jl v0.3.1 and haven't seen a corresponding PR to METADATA. Any ideas?

Thanks!

https://github.com/FluxML/Flux.jl/releases/tag/v0.6.8

Is attobot down now, or is this due to GitHub's recent issues, or something else?

As can be seen here JuliaLang/METADATA.jl#7391 the formatting for the REQUIRE diff is not completely correct. The problem is that I didn't leave a newline at the end of my REQUIRE file so the closing triple backticks happen on the same line as the last REQUIRE entry.

Right now when attobot makes a METADATA PR, it cc's the person who it is making the PR on behalf of.

I suggest it should all tag anyone who is currently Watching the package repo on github.
Because they have selected Watching, which indicates they want to be aware of every thing going on WRT a package.
Presumably, they also want to know when a release is proposed.

I currently have to check this manually, but it would be neat if possible to do here. Parse the .travis.yml, if present, and compare to REQUIRE. If a package still says it supports 0.4, then its travis, if running, should be sure to test against it.

I just updated FluxML/ONNX.jl to v0.1.0. Isn't attobot expected to make a PR for this in metadata.jl? Because there was no PR from attobot's side.

IIUC, the recommended update method here to make changes to an open metadata PR is to leave the PR open, delete the release then replace it, right? Or if you make a new release while an existing PR is still open, does it get added to the same PR or make a new one?

Instead of going back and reading the documentation for attobot before creating the v0.7.1 release of MixedModels I relied on my memory of how attobot works.

Turns out relying on my memoryy wasn't such a great idea.

I used PkgDev.tag("MixedModels") in Julia to tag the package then used the Tags tab on the Github repository to create a release. So Release v0.7.1 does indeed exist on the Github repository but it seems that it did not trigger attobot to create a pull request on the METADATA repository.

What would be a good way of triggering the PR on METADATA?

Suggested by @kshyatt

Attobot should automatically label PRs as to whether they are tagging an existing package or registering a new one.

The problem is that non-contributors can't add labels (and AttoBot probably shouldn't be a contributor on METADATA, as I'm not really convinced there aren't gaping security holes). One option would be to add the functionality to AttoBotDeleter, and give the integration restricted write access to PRs (but not the repository itself). However this will require using the integration authentication, rather than attobot's account.

https://github.com/JuliaInterop/RCall.jl/releases/tag/v0.10.6

It used to work, but it didn’t when I released the latest release. @simonbyrne

As Julia evolves, many packages are built on top of each other and it becomes hard to release a new version with breaking changes. It would be helpful if we, as the authors of a package MyPackage, were able to see right away the impact of the breaking changes in downstream packages.

We can manually do this with:

downstream = Pkg.dependents("MyPackage")
for pkg in downstream
  Pkg.test(pkg)
end

but I wonder if we could have a built-in functionality in attobot for handling this breaking changes more seriously. Do you have suggestions on how that could be achieved?

cc: @tkelman, @sbromberger

Attobot complains about a missing REQUIRE file.
As I understood, the information is moved to Project.toml and manifest.toml and I assume the REQUIRE file is obsolete (because redundant).

If this is so, attobot should accept packages without REQUIRE.

Thank you for your help - attobot is great; it makes package maintenance easy as a walk in the park!
Cordially
Andreas

We may not have this info, but it would be nice if the commit author was set to the person creating the tag, rather than attobot itself.

To avoid nuisance issues on tags of repos that get attobot enabled by accident, like from being in an organization with a lazy admin who clicks "enable on all repos."

See JuliaLang/METADATA.jl#8955 - we could possibly also enforce / fix this there with some git configury, but in that particular case it looks like attobot copied the files as-is with the same line endings as REQUIRE from the package repo.

I had a go at this: I registered packages with Autobot:

then:

julia> using PkgDev
julia> PkgDev.tag("ColorSchemes", :minor)
INFO: Tagging ColorSchemes v1.2.0
INFO: Committing METADATA for ColorSchemes

shell> git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean

shell> git push
Everything up-to-date

shell>  git push origin --tags
Counting objects: 1, done.
Writing objects: 100% (1/1), 171 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To github.com:cormullion/ColorSchemes.jl.git
 * [new tag]         v1.2.0 -> v1.2.0

That's all I have to do? What happens now?

I think you have this planned as a way of solving #6, making it so people can close their PR's if they want without hitting that github force push issue. It's also a big mess to look at the "which branches is this commit in" indicator on anything from attobot's fork, e.g. attobot/METADATA.jl@a8977a0

I registered attabot on https://github.com/yakir12/FFmpegPipe.jl and published a release. Nothing has happened for 10 minutes now (sorry, it said to open an issue after 30 seconds or so). Maybe it has to do with https://github.com/yakir12/FFmpegPipe.jl being a fork of https://github.com/perrutquist/FFmpegPipe.jl ? If so, see here.

I'm in the process of releasing a Hotfix release for BioSequences.jl which will be version 0.6.2, and also doing a release for GeneticVariation.jl JuliaLang/METADATA.jl#9921 (comment)

Yesterday evening, when I tagged the BioSequences.jl v0.6.2 release I noticed that attobot did not create a PR, despite attobot being configured to watch those two packages.

Also, whilst attobot created a PR for GeneticVariation.jl, it has stopped updating it when I made changes to the release in response to comments.

I just enabled attobot on MathProgBase.jl and tagged v0.6.0. It's been a few minutes without a corresponding PR to METADATA.

Thanks!

I am a new user of attobot, I submitted several PR's publishing my new package until
I got the hang of CI , now I want to delete my initial failed attaempts.
How do I delete PR's that attobot already issued in my name?
I deleted the tag and release but the PR is still showing in METADATA repo.

Thanks.

Would love to have the one line package description from github with PRs created by @attobot.

I installed Attobot in order to avoid the complications of PkgDev.

The tutorial says I should open an issue if there is not anything done within some seconds and there has passed several minutes since then. I haven;t gotten any notification on my email, so I checked the PRs at the official METADATA.jl page. I also did not find anything there.

I have had many release versions tagged on github before installing Attobot. After installing attobot I made a new minor tag release, i.e. from v0.5.0 to v0.5.1 .

Let me know what else information I should give you.

Hello,

The instructions for Attobot say that if I don't see a PR within 30 seconds I'm supposed to open an issue. The package in question is here: https://github.com/dcarrera/Planets.jl

I installed Attobot and then I made my first release. After several minutes I don't see any PR in https://github.com/JuliaLang/METADATA.jl/pulls

Please let me know if I've made a mistake somewhere.

Does github send events for that? If so it would be good to signal somehow "this PR is WIP, the submitter just deleted the release that triggered it, don't merge right this moment since the tag sha's might not match." Maybe re-trigger travis (eats a few minutes of queue for something that is likely to fail, not ideal), change the title to WIP until a new version of the release triggers an amended metadata PR commit, or add a "hold on, revision in progress" comment?

The existing model of attobot has worked reasonably well so far:

• It is easy to set up.
• It is able to use the existing GitHub Release UI
• It doesn’t require write access to the repo
• It doesn’t require internal state or a UI, so can be implemented as a single AWS Lambda script.

There are some downsides:

• It is tied to GitHub
• It requires two distinct steps: 1) the creation of a GitHub Release, and 2) someone to merge the result into METADATA.
• The user needs to manually track existing version numbers.
• The mechanism for error handling is poor: for “immediate” problems, an issue is opened on the repo in question; other errors result in CI failures on METADATA, with discussion there.
• Fixing the problem by deleting/modifying a Release before being merged requires multiple steps, not all of which are intuitive.

In addition, Pkg3 presents new challenges:

• The version number is stored in the Project.toml file, and ideally should be kept in sync with the tagged versions
• There can be multiple package registries

Proposal 1: the easy one

We basically keep the current model, and ignore the version number in the Project.toml file, using the version number of the tag instead.

• (optional) It could open a PR (post-tag) to update the Project.toml file so that it isn’t too far out of sync.
• (optional) a .attobot config file containing the registries to which updates should be pushed

Proposal 2: the strict one

Similar to 1, but throw an error if version number in the Project.toml file doesn’t match the tag (perhaps by opening a PR to fix it). It would then require the user to go through the cumbersome process of deleting the Release and retagging (which may be quite frequently).

Proposal 3: watch the Project.toml

Rather than listening for GitHub Releases, we watch the version number in the Project.toml file, tagging a new version whenever it is incremented. It is not exactly clear how this could be handled (e.g. would you only watch certain branches?), and unless it had write access to the repo, there would be no way to create corresponding git tags on the repo itself.

Proposal 4: our own UI

Create our own Pkg UI which would allow users to create new patch/minor/major releases (possibly combined with JuliaCI checks). It could then update the Project.toml via pull requests, though still could not create tags without having write access to the repo.

There's no reason to not care about Windows. It should at least be highlighted during the release process that a package's tests fail or don't fail on Windows in the same way that it is for other OSs.

I drafted LightGraphs 0.7.4 release this morning and it has not shown up at metadata yet. Usually the PR is created within a few seconds.

https://github.com/JuliaGraphs/LightGraphs.jl/releases

It says it was drafted 7 days ago, but I think that's just the date of the last commit. I drafted the release about 20 minutes ago.

I accidentally created a release with a tag name of v0.5.2`` , which caused Attobot to open an issue like this: JuliaLang/METADATA.jl#8409

This probably shouldn't be possible.

I tagged a new release for Hwloc yesterday https://github.com/JuliaParallel/Hwloc.jl/releases/tag/v1.0.0, and attobot should have opened a pull requeste for METADATA. It didn't. How do I proceed?

I tagged v0.1.0 of my package for a new contribution. I got no messages and see no new PR for it on METADATA after 13 minutes.

(An earlier attempt with the tag name "0.1.0" did generate an issue complaining about the tag name.)

MIT is a nice choice :)

Hello, I have just added my stakaz/BracedErrors package to attobot and created a first release by following the steps on the attobot page. But nothing happened after creating the release.

Could someone tell me what was wrong about it? This is my first official package. Thanks.

This might be a decent mechanism for revisions? It would mean metadata reviewers have to check for more variations though.

It would be nice not to reject packages that don't have a REQUIRE, only a Project.toml.

Packages that have transitioned to the new format have to maintain a REQUIRE just for attobot. Cf #48, this discussion

I've received a complaint from attobot: "Error tagging new release. The REQUIRE file could not be found." However, as far as I can tell, the Julia 1.0 docs don't mention a REQUIRE file.

It was mentioned recently that "attobot does need a bit of a revamp for Pkg3", which is understandable. In the meantime, should I appease attobot by creating an empty REQUIRE file?

I had made a release v.08.4 for GeoEfficiency 20 hr ago then I had to delete it and make a commit to the repository then rerelease the version.
for the first part it is all ok. but no action is done on rereleasing even when I edit the release and changed its name.